1. Field of the Invention
The present invention generally relates to electronic circuits and, more specifically, to microcontrollers embedded in electronic devices. The present invention more specifically applies to microcontrollers supported by microcircuit cards or the like and capable of executing programs in the Java language adapted to microcircuit cards, currently called JavaCard language.
2. Discussion of the Related Art
More and more microcircuit cards, be they payment cards, subscriber identification modules (SIM), transport cards, etc. are capable of executing programs in the JavaCard language. It is generally spoken about Java applications (Applet) and of JavaCard Virtual Machines (JCVM).
Any microprocessor adapted to the JavaCard language, and more specifically any microcircuit card microcontroller adapted to such a language, should comply with certain constraints specific to the characteristics of the JavaCard program.
Among such constraints, any update of JavaCard data in a non-volatile memory (generally designated in Java language as a persistent memory) of the circuit must be atomic. In JavaCard, Java data generally correspond to 1 byte, a short word (2 bytes), or a data table. The atomicity of an instruction or transaction (instruction sequence) executed by a microcontroller means that one or several variables involved in this transaction do not risk being provided with any state in case the transaction is interrupted (for example, by loss of the circuit power supply). The simplest case is a variable having an initial state and a final state. The atomicity of a transaction implementing this variable then means that, even if the transaction is interrupted, the variable does not risk being provided at an intermediary state.
This constraint generally leads to deferring data update operations in the non-volatile memory to avoid as much as possible slowing down operations. Thus, the writing of data into the non-volatile memory only occurs at the end of a processing method.
A consequence of such a deferral in the recording in the non-volatile memory is that it is not possible to implement a secure counter. “Secure counter” is used to designate a counter indicating a value that can be considered as reliable regarding the operation or the transaction monitored by this counter. It may be desirable for such a counter to reliably count a number of executions of a JavaCard application, for example, to control the number of diffusions of a content in a toll broadcasting system, to decrement a number of uses of a transport ticket or access pass (cinema, for example), etc.
For such a counter to be reliable, it should be ascertained that a willful or incidental intervention on the card, for example, by interruption of its power supply, does not enable to prevent an update of the counter. To achieve this, the counter update should be atomic during the write operation. Now, in a JavaCard environment, it should be decided for all data updates to be atomic at the time when they are launched, which would considerably slow down the processing.